Talk:Lua
Redirect Wikipedia talk:Lua/To do here While I'm thinking about it, would anyone object to redirecting Wikipedia talk:Lua/To do to this page? At the moment, I think the discussions are too fragmented. We already have two talk pages - here, and Wikipedia:Lua requests. A third seems too much. — Mr. Stradivarius ♪ talk ♪ 12:52, 2 February 2014 (UTC) :No objection here. — Edokter (talk) — 13:20, 2 February 2014 (UTC) :Good idea. Johnuniq (talk) 01:23, 3 February 2014 (UTC) :Good, improvement. -DePiep (talk) 04:58, 2 March 2014 (UTC) mw.loadData Hi, I have a question about this function. I would like to know if loading the same module multiple times from the same module has performance issues (or instead it's the same for some internal cache). Example: local a = mw.loadData("Module:MyModule") -- ... in the same module, somewhere else ... local b = mw.loadData("Module:MyModule") is it more expensive or is it just the same than: local a = mw.loadData("Module:MyModule") ... local b = a Thanks in advance. --Rotpunkt (talk) 12:45, 20 February 2014 (UTC) :mw.loadData evaluates the module only once per article. I'm assuming that means the module data is cached internally, so the performance of both of your examples shouldn't be appreciably different. -happy5214 13:05, 20 February 2014 (UTC) :: The second might be slightly more efficient, because it doesn't create a new wrapper object for the loaded data. It's probably not worth worrying about though. Anomie⚔ 22:18, 20 February 2014 (UTC) ::: Thanks to both of you, and thanks Anomie for the detailed informations. --Rotpunkt (talk) 23:56, 20 February 2014 (UTC) Code editor not showing up? On my work computer the code editor shows up fine, but my home computer doesn't load it at all (no toolbars, no syntax highlighting, no line numbers). Both computers are running Chrome, but the work computer is on XP and the home computer is on Win7. I would expect the newer home computer to load better but it's been the other way around :/ Any ideas why this is happening and how this can be fixed? Thanks. _dk (talk) 16:38, 28 February 2014 (UTC) :You need Javascript enabled in your browser, and the code editor needs to be enabled if it has been disabled. There is an icon at the left of the toolbar just above the edit window which can be clicked to enable/disable. Johnuniq (talk) 22:28, 28 February 2014 (UTC) ::Javascript has always been on (the toolbars are right above me as I type!), but in the Module namespace the toolbars don't even show up, let alone the enable/disable button. _dk (talk) 15:49, 1 March 2014 (UTC) :::We need to get specific. If I enable Javascript and edit Module:Sandbox/Johnuniq/message, I see the following at the top: ::::Content that violates any copyrights will be deleted... ::::Toolbar with "/*" icon at left. ::::Toolbar with "Heading" and "Format" and more. ::::First line of code: "-- Adapt message() from..." :::The "/*" icon is the enable/disable button. On mouse-over it shows "Toggle code editor". There is possibly something in that controls this, but I can't see it. In my preferences, under the Editing tab, I see "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar", but I have both of those off. If you can't find anything, please try WP:VPT. Johnuniq (talk) 01:35, 2 March 2014 (UTC) ::::Going from your example, this is what I see: :::::Content that violates any copyrights will be deleted... :::::Preview of the code :::::First line of code: "-- Adapt message() from..." ::::I suspect it's a memory issue, like how gadgets on Wikipedia will just shut down and not load when I don't have enough RAM? I found that it loads once in a while if I refresh a few times. Thanks for the help anyways. _dk (talk) 18:23, 2 March 2014 (UTC) :::::If it shows up every once in a while, then it sounds like either a connection problem or a lack of system resources on your computer. Sometimes on slow connections the page takes long enough to load that the browser gives up on trying to download the JavaScript, and CodeEditor is implemented in JavaScript, so that means that it won't be run. Also, if your system doesn't have the necessary memory or other system resources to run the JavaScript, then that means it won't be run either. If you are experiencing the same kind of issues with Wikipedia gadgets, then the system resources explanation would make the most sense. You could dry disabling some of your user scripts and see if that helps. — Mr. Stradivarius ♪ talk ♪ 00:38, 3 March 2014 (UTC) Page-global variables Is there a (documented) way of defining a variable whose value is kept in subsequent invocations of a module? For instance, say that I have a module MyTableGenerator. I would first call and then, every call to would generate a table with a red background. On the French Wikipedia, some modules simulate this by calling getContent() on the page itself and doing a regexp search in the source code. I am looking for an alternative. Orlodrim (talk) 21:38, 5 March 2014 (UTC) :There is no mechanism for allowing information to persist from one invoke instance to the next. Dragons flight (talk) 21:45, 5 March 2014 (UTC) :: In fact, it is specifically intended that there not be a way to transfer information from one invoke to the next. VisualEditor and Parsoid want to be able to reparse portions of the page without having to worry about reparsing the whole thing. Anomie⚔ 22:21, 5 March 2014 (UTC) ::* Even worse, there (wa|i)s a way when there is not suppose to be. This will be fixed very shortly if it has not already been fixed... — (t • • ) 23:04, 5 March 2014 (UTC) os.date() not working properly? A week or so ago as the result of a new topic at Module talk:Citation/CS1, I did and experiment in the debug console using this: =os.date("Y") which returned the current year. Today, after adding that code to Module:Citation/CS1/sandbox, I got series of script errors that eventually showed that os.date("Y") is returning Y. I didn't test them all, but the several format characters that I did test simply returned the format character. If the functionality of os.date has been changed, then the os.date documentation is also in need of change. I got round the problem with os.date("*t").year. —Trappist the monk (talk) 15:28, 7 March 2014 (UTC) : I doubt =os.date("Y") ever worked. os.date uses the same syntax as strftime, as is documented, so you'd need =os.date("%Y"). Anomie⚔ 19:34, 7 March 2014 (UTC) ::Argh! Facepalm. Thanks. ::—Trappist the monk (talk) 19:44, 7 March 2014 (UTC) Minor bug I noticed that if I add a strip marker for with nothing in front of it, it generates no text, but adding an "x" in front of it makes it spit out the last reference in an unused variable. https://en.wikipedia.org/w/index.php?title=Module:User:Wnt/Sandbox&diff=600626756&oldid=600626674 There are a bunch of things that could affect that, and I know the code was being worked on because of side effects from ref tags carrying from one routine to the other. I doubt it matters to real-world examples unless it's something more general, but might as well ask if anyone recognizes the problem. Wnt (talk) 18:14, 21 March 2014 (UTC) :I see what's going on. Calls to frame:preprocess are cached somewhere, so the first time you run frame:preprocess("") it caches the blank result, then the next time, instead of actually parsing it, it returns the blank result again. When you do frame:preprocess("x"), it doesn't have it cached, so you get the right result. If you change both functions to frame:preprocess("x"), then it's cached again, so it stops working again. ping. Jackmcbarn (talk) 19:37, 21 March 2014 (UTC) :(Also, as a side note, you have to unstrip it to see it). Jackmcbarn (talk) 19:38, 21 March 2014 (UTC) ::Thanks - I verified the bug does behave as you suggest (I should clarify that the unstrip is not required to see the change in output, though it may be useful in debugging it) Wnt (talk) 21:42, 21 March 2014 (UTC) ::I just tried a different test https://en.wikipedia.org/w/index.php?title=Module:User:Wnt/Sandbox&oldid=600655486 that doesn't use strip markers, and those aren't cached: a set of frame:preprocess() of things like "#. Pennsylvania" doesn't repeat the numbers. So far I can't think of a strip marker other than that should change while the page is put together (well, the system timestamp should change a little, but it's neither predictable nor guaranteed...), so maybe a very specific fix would work, and it may indeed be quite minor of a bug anyway. Wnt (talk) 21:54, 21 March 2014 (UTC) :::I think you're correct that as of right now, only and have side effects. This is a general issue with Extension:Cite that there's really no good fix for. Jackmcbarn (talk) 22:30, 21 March 2014 (UTC) :::: I tried to fix it, but the Parsoid people wouldn't go for it. They'd rather add a whole extra pass to the parser, basically re-parsing the page to handle the references after the normal parse put in placeholders. Anomie⚔ 03:26, 22 March 2014 (UTC) ::::: Wow. Looks like this bug has been known a long time and does have a very serious effect, if you still can't use twice on the same ordinary wiki page without bugged output. I'm surprised people have put up with that. Your reaction reminds me a little of when I was on about those beloved mw.message hacks before -- I think those words "not encourage" tend to have that effect on a person -- though admittedly life with multiple developers revising a mountain of code with a Freddy Krueger pedigree may teach people to think differently about these things. But... to me that last comment by GWicke "I guess it *is* different if you see this as just a temporary and internal flag to be used by Cite only. I'm fine with that if documented clearly." sounds like it was leaving the door open a crack, maybe? Wnt (talk) 14:55, 22 March 2014 (UTC) CodeEditor Feedback desired Please read and give your input about what you are looking for in the CodeEditor toolbar —TheDJ (talk • ) 00:14, 26 March 2014 (UTC) The Lua editor What is a (the) basic Lua editor, and how do I get one? Right now, I can't even search & replace, and irregularly (or Byzantine) every next Lua edit mode alters editor. -DePiep (talk) 22:28, 30 March 2014 (UTC) :The default is CodeEditor, which loads automatically when you edit a module page (or a .js or .css page). Do you see it when you edit a module page? It looks like this, although the colour scheme has changed since that screenshot was taken. A lot of the settings are only available through keyboard shortcuts at the moment - for example, search and replace is accessible by pressing CTRL+F twice (CTRL+F once is just search). See here for a list of default shortcuts. Myself, I use a combination of GVim and It's All Text, but the setup process for that is fairly involved, and GVim has a steep learning curve. — Mr. Stradivarius ♪ talk ♪ 02:04, 31 March 2014 (UTC) ::One subtle point is that if you ever click the "/*" icon at the top left of the "looks like this" link from Mr.S's post, you will switch the code editor off, and it stays off until you click that icon again. On the point of an external editor, I saw the recent discussions regarding enhancements to the amazingly feature-rich CodeEditor, and personally I would worry a lot about the prospect of using a browser for a serious coding session. Like many people, my network and computer and software are very reliable, but I would never spend more than five minutes editing in a browser edit window because the slightest glitch would cause everything to disappear. I once investigated things like "It's All Text", but in the end decided that copying between browser and editor was sufficiently simple that I wouldn't bother with another layer. Johnuniq (talk) 03:15, 31 March 2014 (UTC) :::I agree about the external editor point. When I've edited with CodeEditor in the past, I've lost my work on more than one occasion by pressing CTRL+R instead of CTRL+F. In most browser setups, CTRL+R refreshes the page, which means that you lose everything that you've done since your last edit. I understand that there's a fix in the works to bring up a dialogue in CodeEditor if you try and navigate away from the page, but in general it is still safer to stick with an external editor. — Mr. Stradivarius ♪ talk ♪ 04:20, 31 March 2014 (UTC) ::::I also use an external editor for most coding. I'm partial to Vile instead of Vim, but that is only because of starting to use it a long time ago. At this point, Vim is probably a better choice, given its popularity (implies more developers). However, I have not really compared the two. ::::I have not done a large amount of editing using the CodeEditor. For normal Wikipedia page editing I rely on the Firefox extension Textarea Cache to auto-save the textbox data. It appears to work reasonably well. Recovering from a Firefox crash – dramatically more frequent for me starting about 2 months ago – is easy and results in minimal loss. It, unfortunately, does not work on the CodeEditor edit box. I must admit that I had assumed that Textarea Cache would save the text area when using CodeEditor. However, I just tested it and it does not. I have not looked for an automatic solution to auto-saving the CodeEditor text area yet. If I don't find something easily, I'l probably hack Textarea Cache. On the other hand, I'll probably end up just using Vile. ::::As to the ctrl+R issue in CodeEditor: At least on Firefox, once you have clicked on either "Show preview" or "Show Changes" the ctrl+R will result in a pop-up asking if you want to resend the data instead of automatically re-loading the page. Thus, a workaround for that issue is to click "Show changes" every time you start editing a page with CodeEditor. For most other pages, Firefox already pops up a confirm dialog if you are leaving the edit page once the contents of the textbox change. — Makyen (talk) 05:52, 31 March 2014 (UTC) Thank you all for your careful replies. Still, I am not looking for any 'external' solution, nor for a CE manual. I just want the default editor for modules to function. CE does not. And up in the tree (via WP:VPT to mw:) I have not met a single interest about for this. One peculiar recent branch is Wikipedia:VPT#CodeEditor_Feedback_desired OP by TheDJ, which shows activity but does not gave me a single useful link. -DePiep (talk) 20:26, 13 April 2014 (UTC) :CodeEditor is the default. If you have a problem, please come talk to me about it and I'll see what I can do. The above and earlier comments don't really give me enough context. There is a known problem with WikEd leading to unexpected behavior, and that will eventually be solved. If you have OTHER problems (so you have fully disabled the WikEd gadget in your preferences and still have problems), then please describe them, tell me your browser/OS version, file bug reports in bugzilla, make screenshots or basically ANYTHING that makes it actionable instead of vague remarks. Also, don't expect me to solve it within a week, I'm a volunteer and I don't always have time to solve complicated problems within short notice. But currently, i simply still don't understand what your problem is, proving that in 3 threads you have not done enough to explain it to me. —TheDJ (talk • ) 12:47, 23 April 2014 (UTC) :: Yes, it's very hard for us to know what the problem is if you don't do some troubleshooting first. Try and disable WikEd, bypass your cache, and then see if CodeEditor works. If not, try and disable other gadgets and user scripts until you find what the conflict is. — Mr. Stradivarius ♪ talk ♪ 13:00, 23 April 2014 (UTC) :::Or look in the console. If CodeEditor fails to load, then it'll probably throw an error and that's shown in your browser's JS console. — lfdder 13:19, 23 April 2014 (UTC) Creating a central, CS1-like Module to standardize Infobox template code? At the moment, the way analogous tasks in different Infobox templates are done seems diverse and arbitrary. Take, for example, listing the non-English name of a (thing) in that (thing) s Infobox. I've seen non-English names put in the same parameter as the English one, but with a in the middle;Foreign and Commonwealth Office has: put in a separate, non-language-specific parameter;China has: }} | }} and put in separate, language-specific parameters.Anhui has: :I'd like to point out that user Hoo man has been working on an extension with a lua module called Capiunto, that makes it easier to build Infoboxes in a more consistent method for sites (not every wiki has an active template community, able to handle all of these problems themselves). Taking this up to the level of content, parameter naming conventions and value validation goes a bit further then what Capiunto was envisioning so far, but it might be something to keep an eye on. —TheDJ (talk • ) 12:32, 23 April 2014 (UTC) Module:Yesno update I'm thinking of updating Module:Yesno from the version at Module:Yesno/sandbox - please see Module talk:Yesno#New version if you're interested in commenting. — ''Mr. Stradivarius'' ♪ talk ♪ 15:25, 7 April 2014 (UTC) Trouble of template inheriting module parameters I've created module:MTR and its "icon" function is invoked by . The icon function apparently looks OK when the arguments "text" and "link" are given values directly as shown in the module doc. But when I transclude the module in the said template with parameters 2 and 3 inheriting arguments "text" and "link" of the module respectively with parser function #IF:, the values for these 2 arguments are seemingly ignored completely. Please help. -- Sameboat - 同舟 (talk) 08:40, 10 April 2014 (UTC) :I've simplified the template invocation. Let me see what I can make of the module. — ''Mr. Stradivarius'' ♪ talk ♪ 09:45, 10 April 2014 (UTC) ::Hmmm, I should retire. I took a quick look at the template and thought that there was no reason to pass the template's parameters in that fashion, and then blanked that out of my mind and used what "should" have worked (local args = frame:getParent().args), but that failed with the way it is actually used. I started just before you replied here, so I'll leave this to you. Johnuniq (talk) 10:13, 10 April 2014 (UTC) ::: Ok, I've finished. I actually had second thoughts and used frame:getParent, so there are now no parameters in the template invocation. I've also moved the data to Module:MTR/data so that it can be loaded with mw.loadData. using frame:getParent means that the arguments are passed straight through to the module from template invocations like . And using mw.loadData means that we cache the data so that it only has to be processed once per page, rather than once per #invoke, which should boost performance. It also has the bonus that we can put the data in a more easily-readable format. Let me know if it's all working as it should, and feel free to ask if you have any questions about the code. You've made a great start programming in Lua, and I'll be happy to help you improve. :) — ''Mr. Stradivarius'' ♪ talk ♪ 11:35, 10 April 2014 (UTC) ::Sadly your simplification for the template doesn't work. You can see the result in the examples of the template doc (may need purge). -- Sameboat - 同舟 (talk) 11:24, 10 April 2014 (UTC) ::: Ah, sorry about that. That's because I made it so that accessing the module directly via #invoke won't work, but accessing it through a template will. That's easy to fix, but it will make the module slightly slower, and should probably be avoided if it's going to be used many times on one page. I've updated the examples on the module page to use the templates rather than to use #invoke. — ''Mr. Stradivarius'' ♪ talk ♪ 12:02, 10 April 2014 (UTC) ::::Thank you very much. I'm relatively new to lua and this is the first ever real module I've ever created as you can tell from the original layout, so I need some time to catch up to your optimization. -- Sameboat - 同舟 (talk) 12:34, 10 April 2014 (UTC) :::: Just one more thing. The "colorbyname" function also needs to change the argument value to all caps as in "icon" function. I simply copy code = code:upper() to the "colorbyname" table. Is it possible to simplify this step so the same uppercase command doesn't need to repeat in case more functions are implemented to the module later? -- Sameboat - 同舟 (talk) 14:40, 10 April 2014 (UTC) :::::Yes, you can put something like this in the makeInvokeFunction function: local code = args1 or '' code = code:upper() args.code = code :::::That way you only have to do it once. It also means that will always be retrieved from wikitext, but that's fine here as it's going to be used in both functions anyway. — ''Mr. Stradivarius'' ♪ talk ♪ 14:57, 10 April 2014 (UTC) ucfirst What would be the code to produce an (first character into uppercase)? I am expecting string functions and patterns. -DePiep (talk) 20:29, 13 April 2014 (UTC) : mw.ustring.upper(mw.ustring.sub(str, 1, 1)) .. mw.ustring.sub(str, 2)Jackmcbarn (talk) 20:36, 13 April 2014 (UTC) ::Aaahrgh ... no pattern needed. Thanks. (I consider, my last frustrating hours & edits were a "learning experience"). -DePiep (talk) 20:43, 13 April 2014 (UTC) :::You can also use . — ''Mr. Stradivarius'' ♪ talk ♪ 12:30, 22 April 2014 (UTC) mw.html library nil behaviour There is an interesting discussion on Bugzilla now about the mw.html library. The question is, should the mw.html methods like attr, css, cssText and addClass accept nil values as input? At the moment, passing a nil value to those methods generates an error. This is because nil is not a valid css value, attribute or class. It prevents module writers from making mistakes where they may have assumed a variable always has a string or number value, whereas sometimes it is in fact nil. The counter-argument is that not accepting nil values prevents module writers from call-chaining as easily. With accepting nils, a call chain might look like this: local root = mw.html.create('table') root :tag('tr') :tag('td') :css('color', args.color) :wikitext('some text') return tostring(root) Without accepting nils, the same call-chain might look like this: local root = mw.html.create('table') local cell = root:tag('tr'):tag('td') if args.color then cell:css('color', args.color) end cell:wikitext('some text') return tostring(root) You can see more details at bugzilla:62982. What would people prefer to do? Is the error-checking more important than the call-chaining, or is it more important that call-chaining should work without using if statements? Please leave your opinion below if you are interested. — ''Mr. Stradivarius'' ♪ talk ♪ 13:14, 22 April 2014 (UTC) : Surely I prefer that the library accepts nil values to allow call-chaining. --Rotpunkt (talk) 13:53, 22 April 2014 (UTC) ::According to my request. Hlm Z. (talk) 16:18, 22 April 2014 (UTC) : yes, allowing nil makes it much more readable. or, at the very least, have a value which can be passed which causes it to do nothing. I am currently using args.color or '' which creates an empty "color:;", which is suboptimal. Frietjes (talk) 17:02, 22 April 2014 (UTC) ::If preserving the principle only is the point ("there is no tag 'nil'"), then default to: accept nil for 'blank'. ::If the 'nil' value serves anything, then keep it (for example, in argument processing it could mean something). ::But for sure we should not, asap, introduce another blank=/=undefined parsing. -DePiep (talk) 20:11, 30 April 2014 (UTC) :::Let me add. The }}}}}|a|b}} code issue has cost me thousands of edits & puzzles & hours without being productive. (Then enter the question of } vs. } in subtemplates). The reversed "nil=blank & you can code otherwise" solution is better. -DePiep (talk) Let's not get the code examples get too terrible local root = mw.html.create('table') local cellcolor = args.color or 'black' -- or something else, but at least the default is explicit root :tag('tr') :tag('td') :css('color', cellcolor) :wikitext('some text') return tostring(root) seems reasonable to me, and fairly sound. Another option is making css('', '') a nop, at the cost of an extra local. Or even local root = mw.html.create('table') root :tag('tr') :tag('td') :css('color', args.color or 'inherit') :wikitext('some text') return tostring(root) Martijn Hoekstra (talk) 20:53, 30 April 2014 (UTC) ::Our edits must have crossed. ::I state: "nil=blank & you can code otherwise" (contrary to current }}}}}|a|b}}. The horror). -DePiep (talk) 21:02, 30 April 2014 (UTC). :Using isn't ideal, as you're setting an explicit style in the module that now can't be styled using user stylesheets without using "!important" overrides. Using is a lot better, and could be very useful - thanks for pointing it out. That doesn't help with addClass or attr, though, which don't have similar non-nil fallback values, as far as I'm aware. Conditional classes and attributes would still have to be added using if/then statements. — ''Mr. Stradivarius'' ♪ talk ♪ 10:32, 1 May 2014 (UTC) ::All options look fairly unappealing to me to be honest. Making a function with invalid arguments a nop is terrible. Appending non-functional (and even somewhat harmful) css because the code looks better is also terrible. Isolating different elements to make if statements happy is also terrible. Other options are even insanely more terrible (patching the metatable to do smart things that are incomprehensible, or doing a conditional over the if up front and passing either the css or identity function down the code, other lovecraftian horrors). I guess it's somewhat user dependent what one considers the most and least terrible. Martijn Hoekstra (talk) 12:58, 1 May 2014 (UTC) ::Actually, is a bad idea as well, because there's a lot of styles that don't get inherited by default. Jackmcbarn (talk) 13:16, 1 May 2014 (UTC) :::Hence the 'and even somewhat harmful'. I fully concede that this too is terrible. Martijn Hoekstra (talk) 13:20, 1 May 2014 (UTC) Another terrible idea might be to introduce methods that make explicit noop is an intentional possibility: return tostring(mw.html.create('table') :tag('tr') :tag('td') :if_css('color', color) :if_wikitext(text) ) --darklama 19:38, 8 May 2014 (UTC) I very much support the proposed change. The entire purpose of HtmlBuilder was to reduce and simplify the code needed to generate HTML. Nil values were accepted as a NOP in HtmlBuilder to support the extremely common use case of a module that accepts optional arguments, and reduce the boiler-plate clauses. The only justification for the input checking is some paternalistic view that programmers should check for valid values before passing them to a function. But the values are only invalid if they violate the contract of the function. If the contract of the function is to accept nil values as a NOP, then everything is fine. It seems to me that changing the contract now would make mw.html easier to use, would not break any currently working code, and would improve compatibility with HtmlBuilder. Toohool (talk) 04:55, 9 May 2014 (UTC) :Well said. Otherwise, why not require a check for input being unicode too? -DePiep (talk) 06:15, 9 May 2014 (UTC) ::I don't thing "a check for input being unicode" means anything. Martijn Hoekstra (talk) 14:37, 9 May 2014 (UTC) :I agree values are only invalid if they violate the contract of the functions. The contracts of the mw.html functions are incompatible with the HtmlBuilder functions, which makes switching to mw.html harder then most people probably assume. If mw.html's contract is to return an error-free string then mw.html must depend on the mediawiki parser to validate tag names, attribute names, attribute values, CSS property names, CSS property values, and wikitext passed as arguments. I think nil, false, and "" should be interpreted as wanting to remove a HTML attribute or CSS property, and should silently do nothing if the HTML attribute or CSS property hasn't been set yet. My example above is meant as an alternative to satisfy any view that functions should do as the function names suggest, if that is the reason for not maintaining HtmlBuilder's contract. --darklama 14:15, 9 May 2014 (UTC) ::The buzilla discussion, and the intro by mr. Stradivarius here, centers around "This is because nil is not a valid css value, attribute or class". However, that same argument is not applied to input like :tag('sapn'). For this situation, the argument "you must check your input beforehand" is not applied. -DePiep (talk) 11:52, 10 May 2014 (UTC) :::Yes, the argument to check input beforehand is not being consistently applied, when applied at all that argument should be consistently applied. Another problem with the check input beforehand argument is the way the argument is being applied means checks are performed twice, once beforehand and again within each function call, which at the most optimized is still O(n*2). If checks beforehand are to be expected, mw.html should instead include validate(input, type) or individual validateType(input) functions to use before passing the input to the other functions, and let the other functions fail horribly and silently when passed invalid input. --darklama 14:46, 10 May 2014 (UTC) ::::There's no such complexity class as O(n*2). Twice as long as O(n) is still just O(n). There is an O(n^2), but that's definitely not what would happen in that case. Jackmcbarn (talk) 14:51, 10 May 2014 (UTC) :::::O(n*2) is a correct writing, and it describes the point made. And O(n) is not a complexity class. -DePiep (talk) 16:30, 10 May 2014 (UTC) :Of all terrible ideas, IMO that one is the least terrible. Kudos for finding it :) Martijn Hoekstra (talk) 16:33, 10 May 2014 (UTC) ::::::Even if complexity was the wrong word, you still don't use coefficients in big-O notation. Jackmcbarn (talk) 17:23, 10 May 2014 (UTC) :::::::Almost right: in this case, don't use the big O(), and keep the factor two. But the topic is something else. -DePiep (talk) 11:22, 11 May 2014 (UTC) Odd problem with new template/module I'm having an odd problem with a module/template I'm working on at and Module:zh . When it appears on its own in a paragraph, i.e. with blank lines either side, it seems to swallow white space. Compare that with the current template used identically This likely isn't much of a problem given how it's used, normally inline with text, e.g. Beijing ( ) is the capital of China ( ), which means an obvious 'fix' of generating blank lines (e.g. para breaks) within the template would only make things worse. I can't see anything though that's causing this. It only seems to happen with white space - I used lists here: Template:Zh/testcases with no problems.--JohnBlackburnewords 16:58, 26 April 2014 (UTC) : It's doing that because the lines end with Category:Articles containing Chinese-language text (which seems like it may be a bug). Jackmcbarn (talk) 17:02, 26 April 2014 (UTC) :Indeed, it's bugzilla:17988. Jackmcbarn (talk) ::OK, thanks. Yes, It's different from the current template that embeds them more deeply in output, given the logic they seemed more sensible at the end but i can easily 'fix' it. The use of categories here is perhaps a bit unusual but then again citation templates do something similar, so it's odd if it's not been noticed before. Maybe people have just worked around it.--JohnBlackburnewords 17:13, 26 April 2014 (UTC) :::I'd delegate lang-tagging and categorisation to , personally. In fact, why can't be just a wrapper for lang/lang-x? Anyway, you might be interested in contributing to Module:Language. — lfdder 17:27, 26 April 2014 (UTC) "Three-column" table What would be the code to create a three-column table, and then edit and read a cell? In other languages, I am used to something like array t1j. (A link to a good example module is welcome too). -DePiep (talk) 11:15, 11 May 2014 (UTC) :What do you mean by "three-column"? If you want to create a 3x3 grid, you can do it by nesting tables: local grid = { {'a1', 'a2', 'a3'}, {'b1', 'b2', 'b3'}, {'c1', 'c2', 'c3'} } :To read the "b3" value, and then write a new value to it, you would do this: local b3 = grid23 mw.log(b3) -- gives "b3" grid23 = 'foo' b3 = grid23 mw.log(b3) -- gives "foo" :Was that the kind of thing you had in mind? — ''Mr. Stradivarius' ♪ talk ♪ 13:29, 11 May 2014 (UTC) ::Yes, exactly this. Thanks. (In initiation the curly brackets are nested, and in approaching the coordinates 23 are linear -- that's what I could not figure). -DePiep (talk) 17:44, 11 May 2014 (UTC) Move this page Hi, Scribunto it's a little bit different than Lua. In Wikipedia, we have Scribunto, not Lua. In consequence it's beter to name this page Wikipedia:Module. Thanks to say me what do you think about that, Regards, --Juanes852 (talk) 11:49, 16 May 2014 (UTC) P.S Excuse-me for my bad english, but I'm a French speaker. :If I understand this topic well: in the future, Scribunto could cover other script languages as well. Next to Lua. So focussing on Lua is OK. IN the future, there could be a Scribunto-handled script "HollywoodScript" sitting next to this Lua. :It is not so that the Lua-in-wiki language is called Scribunto. :PS A HollywoodScript language probably would be useful for vapor, vanity, tinsel and non-existing topics ;-) . -DePiep (talk) 12:14, 16 May 2014 (UTC) :Maybe one day this will change but right now Scribunto is Lua on Wikepedia. Yes, WP:Lua is not the same thing as Lua, but WP:Verifiability is not the same as Verifiability. If you want to learn about Lua go to Lua. If you want to learn about, or participate in, Lua on Wikipedia come to Wikipedia:Lua. Meanwhile redirects help anyone expecting to find this page at another plausible location such as WP:Scribunto.--JohnBlackburnewords 13:22, 16 May 2014 (UTC)